1. Field of the Invention
Embodiments of the invention generally relate to simulation of logic designs and, more specifically, to a method and apparatus for implementing communication between a software side and a hardware side of a test bench in a transaction-based acceleration verification system.
2. Description of the Related Art
In electronic design automation (EDA), functional verification is the task of verifying that a logic design conforms to its specification. Logic simulation is the process of simulating a logic design before the logic design manufactured as integrated circuits (ICs). In software simulation, a description of the logic design is simulated on computers or workstations. Logic designs may be described using various languages, such as hardware description languages (HDLs) or other more abstract languages (e.g., synthesizable SystemC). In software simulation, engineers write a test-bench program to functionally verify the logic design by providing meaningful scenarios to check that, given certain input stimuli, the design performs to specification. A test-bench may be written using various languages, including lower-level languages, such as very high speed integrated circuit HDL (VHDL), Verilog, and the like, as well as more abstract languages, such as C/C++, SystemC, SystemVerilog, and the like. Higher-level languages, such as SystemC, enable engineers to write more abstract test-bench models for simulation, such as transaction-level models (TLMs), as opposed to lower-level register transfer level (RTL) models. Pure software simulation, however, decreases in performance as the logic design becomes larger and more complex.
Simulation acceleration addresses the performance shortcomings of pure software simulation. In simulation acceleration, the logic design is mapped into a hardware accelerator to provide a design under verification (DUV), which allows the design to run much faster than on a general-purpose computer or workstation. The test-bench continues to run using a software simulator on a computer or workstation. A communication channel connects the software simulator and the hardware accelerator to exchange data between the test-bench and design. In signal-based acceleration, actual signal data is exchanged between the test-bench and design. Signal-based acceleration is also referred to as lock-step acceleration, as the software simulator and the hardware accelerator are normally locked together cycle-by-cycle. In simulation acceleration, verification of the logic design can only run as fast as the slowest element in the chain, which is typically the software simulator. With a very efficient test-bench, such as a TLM-based test-bench, the communication channel between the software simulator and the hardware accelerator may become the bottleneck.
Transaction-based acceleration (TBA) is a methodology that overcomes some of the performance limitations of signal-based acceleration and, in some instances, can achieve performance close to in-circuit emulation. In the TBA methodology, a TLM-based test-bench runs on a software simulator at an un-timed level of abstraction and communicates with a DUV on a hardware accelerator through an abstraction bridge. By “un-timed” it is meant that the test-bench has no notion of a clock, but rather exchanges data with the DUV in the form of messages (transactions). The abstraction bridge provides an interface between the un-timed test-bench model and the RTL-based DUV in the hardware accelerator. The abstraction bridge facilitates the exchange of messages between the software model (test bench running on the simulator) and the hardware model (DUV running on the hardware accelerator) using transactors. A transactor may decompose an un-timed message from the software model to a series of cycle-accurate clocked events for the hardware model. Conversely, a transactor may compose a series of clocked events from the hardware model into a single message for the software model.
In particular, a transactor includes three partitions: a software side, a hardware side, and one or more communication channels. The software side is the un-accelerated partition that runs on the software simulator with the test-bench. The hardware side is the accelerated partition that runs on the hardware accelerator with the DUV. It is necessary that a transactor operate as one logical unit, which requires the software and hardware partitions to communicate with each other. This communication is performed using available communication channels.
In a test-bench environment, a logical transactor is represented as an instance of the software side partition and an instance of the hardware side partition. The required endpoints of the communication channel(s) are embedded into the physical partitions and are connected via a binding process. The location of each physical partition of a transactor is dependent upon the needs of the test-bench. Therefore, the actual location of the software side partition, within the test-bench hierarchy, differs from the location of the hardware side partition. To allow the two physical partitions to operate as a single logical unit, the software side partition must have knowledge of the location of the hardware side so that the endpoints of the communication channel(s) can be bound during verification. Once the endpoints are bound, the communication channel(s) are formed. The current approach to provide the software side partition with the location of the hardware side partition requires that the user manually provide the location of the hardware side partition. This computed location takes the form of a hierarchical path from a designated reference point. The hierarchical path is then annotated to the software side partition by the user.
There are several disadvantages to manually annotate the software side partition with the location of the hardware side partition. First, the hierarchical path can be derived or entered incorrectly by the user, resulting in errors during verification. Different tests that require changes to the test-bench architecture result in revised hierarchical paths, requiring the user to re-annotate the software side partition. In some cases, test-benches are not portable between simulation acceleration platforms due to differing reference points for the hierarchical path. Finally, the need to manually annotate the software side partition increases the workload of the user. Therefore, there exists a need in the art for automatic binding of transactor communication channel endpoints in transaction-based acceleration platforms for functional verification.